feat: create credential providers before synthesizing a deploy - #2123

The existing collision check compares the .env.local variables the credentials
in the spec write today, so it cannot catch a clash with a field the CLI no
longer writes but still reads — an OAuth client id, which pre-0.29 projects
keep in AGENTCORE_CREDENTIAL_<NAME>_CLIENT_ID — or with one a later credential
type adds. An api-key credential named 'svc-client-id' therefore added cleanly
and its key was then read as the client id of an OAuth credential named 'svc'.

Names whose derived variable ends in a field suffix are now refused at add
time, the way main's validateCredentialNameEncryptable refuses them. The check
stays in the add flow rather than the schema so that a project already holding
such a name keeps loading and can be repaired.

…ider

Deploy reused an existing provider untouched, so editing a secret in
.env.local and redeploying had no effect on AWS: the provider kept the value
it was created with, and nothing said so. main's deploy updates instead —
`// Always update to ensure provider has current credentials` — and losing that
on the rewrite would be a silent regression for anyone rotating a key.

A credential whose secret the CLI can see is now written on every deploy:
created when the provider is absent, updated when it is present. A credential
with no secret to offer — nothing in .env.local and no external reference —
leaves an existing provider exactly as it is, so a project that provisioned
once and no longer keeps the secret on disk still deploys; only an absent
provider fails, as before.

Provisioning read agentcore/.env.local and nothing else, so a deploy from CI
had to write its secrets to disk first. main reads every credential variable
from process.env and merges it over the file, which is what makes a
non-interactive deploy possible without persisting secrets.

Variables carrying the credential prefix now override the file. The filter
keeps the deploy from reading anything else out of the environment, and the
provisioner takes the environment as an argument so tests do not mutate the
process's own.

`project add credentials payment` and `add payment-connector` write a payment
credential to the spec, but deploy refused to provision one — it threw and told
the user to remove it — so a project could be assembled that added cleanly and
then could not deploy at all. main provisions them, and the CDK construct that
wires payment connectors already reads their ARNs out of the credentials map in
deployed-state.json.

- Core's Identity client gains the payment provider operations. The pinned SDK
  carries them, so unlike main there is no hand-signed HTTP request.
- A payment credential is created when absent and updated when present, from
  the vendor's variables: CoinbaseCDP's api key id, api key secret and wallet
  secret, or StripePrivy's app id, app secret, authorization private key and
  authorization id. Every variable that is unset is named in one error rather
  than one per attempt, and an existing provider is left alone when they are
  all absent.
- Teardown deletes the payment providers the project declares, as main's
  cleanupPaymentCredentialProviders does, after the stack rather than before,
  since a resource in it may still be using one. Only payment providers: an
  api-key or OAuth provider is named account-globally and may be shared with
  another project.

The payment collision test now asserts what actually guards that case: a name
ending in a payment field suffix is refused on its own, so a credential can no
longer be created that would collide with a payment credential's variables.

Resolving every credential before writing any removes the likeliest cause of a
half-provisioned deploy — a missing secret — but not the rest: a create that
fails on throttling or permissions after an earlier one succeeded left a
provider in AWS that deployed-state.json never recorded. Retrying adopted it by
name, but abandoning the deploy or dropping the credential orphaned it.

A failure during the write loop now deletes the providers that same run created,
newest first, and rethrows the original error. A provider that already existed
is not deleted: this deploy only updated its secret, and undoing that would need
the value it held before, which the CLI never had. A deletion that fails is
reported — naming the provider and saying the next deploy will adopt it —
rather than replacing the error that stopped the deploy.